Multipath TCP with mesh access

ABSTRACT

Systems, methods and computer software are disclosed for providing Multipath Transmission Control Protocol (MPTCP) with mesh access. A multi Radio Access Technology (RAT) base station gateway having a MPTCP proxy, proxies an initial MPTCP connection from a User Equipment (UE). The multi-RAT base station gateway determines if the UE is capable of MPTCP to provide MPTCP. When the UE is capable of MPTCP, then the multi-Rat base station provides a Wi-Fi connection and an LTE connection. When the UE is not capable of MPTCP, then the multi-RAT base station provides an LTE connection.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119(e) to U.S.Provisional Pat. App. No. 62/702,257, filed Jul. 23, 2018, titled“Multipath TCP with Mesh Access,” which is hereby incorporated byreference in its entirety for all purposes. This application also herebyincorporates by reference U.S. patent application Ser. No. 15/241,060,entitled “Cell ID Disambiguation” and filed Aug. 18, 2016, which itselfis a non-provisional conversion of, and claims the benefit of priorityunder 35 U.S.C. § 119(e) to, U.S. Provisional Pat. App. No. 62/206,666,filed Aug. 18, 2015 with title “Cell ID Disambiguation,” each herebyincorporated by reference in its entirety. As well, U.S. Pat. No.8,867,418 and U.S. Pat. App. No. 20140133456 are also herebyincorporated by reference in their entireties. The present applicationhereby incorporates by reference U.S. Pat. App. Pub. Nos. US20110044285,US20140241316; WO Pat. App. Pub. No. WO2013145592A1; EP Pat. App. Pub.No. EP2773151A1; U.S. Pat. No. 8,879,416, “Heterogeneous Mesh Networkand Multi-RAT Node Used Therein,” filed May 8, 2013; U.S. Pat. No.8,867,418, “Methods of Incorporating an Ad Hoc Cellular Network Into aFixed Cellular Network,” filed Feb. 18, 2014; U.S. patent applicationSer. No. 14/777,246, “Methods of Enabling Base Station Functionality ina User Equipment,” filed Sep. 15, 2016; U.S. patent application Ser. No.14/289,821, “Method of Connecting Security Gateway to Mesh Network,”filed May 29, 2014; U.S. patent application Ser. No. 14/642,544,“Federated X2 Gateway,” filed Mar. 9, 2015; U.S. patent application Ser.No. 14/711,293, “Multi-Egress Backhaul,” filed May 13, 2015; U.S. Pat.App. No. 62/375,341, “S2 Proxy for Multi-Architecture Virtualization,”filed Aug. 15, 2016; U.S. patent application Ser. No. 15/132,229,“MaxMesh: Mesh Backhaul Routing,” filed Apr. 18, 2016, each in itsentirety for all purposes, respectively. This application also herebyincorporates by reference in their entirety each of the following U.S.Pat. applications or Pat. App. Publications: US20150098387A1;US20170055186A1; US20170273134A1; US20170272330A1; and Ser. No.15/713,584.

BACKGROUND

Multipath Transmission Control Protocol (MPTCP) enables inversemultiplexing of resources, and thus increases TCP throughput to the sumof all available link-level channels instead of using a single one asrequired by plain TCP. Multipath TCP is backward compatible with plainTCP. Multipath TCP is particularly useful in the context of wirelessnetworks; using both Wi-Fi and a mobile network. In addition to thegains in throughput from inverse multiplexing, links may be added ordropped as the user moves in or out of coverage without disrupting theend-to-end TCP connection.

The problem of link handover is thus solved by abstraction in thetransport layer, without any special mechanisms at the network or linklevel. Handover functionality can then be implemented at the endpointswithout requiring special functionality in the subnetworks—in accordanceto the Internet's end-to-end principle. Multipath TCP also bringsperformance benefits in datacenter environments. Multipath TCP canbalance a single TCP connection across multiple interfaces and reachvery high throughput. MPTCP is defined in IETF RFC 6824, which is herebyincorporated by reference in its entirety.

Smartphones (UEs) have a motivation for using MPTCP as this would allowthem to efficiently exploit their 4G/3G and Wi-Fi interfaces in paralleland provide seamless mobility. However, MPTCP must be supported on boththe smartphones and the application server.

SUMMARY

Systems, methods and computer readable mediums for multipath TCP withmesh access are described. In one example embodiment, a method forproviding Multipath Transmission Control Protocol (MPTCP) with meshaccess includes proxying, by a multi-Radio Access Technology (M-RAT)base station gateway having an MPTCP proxy, an MPTCP connection with aUser Equipment (UE). The method also includes determining, by the M-RATbase station gateway, if the UE is capable of MPTCP to provide MPTCP.The method further includes when the UE is capable of MPTCP, thenproviding, by the M-RAT base station gateway, a Wi-Fi connection and anLTE connection; and when the UE is not capable of MPTCP, then providing,by the M-RAT base station gateway, an LTE connection.

In another example embodiment, a system for providing MultipathTransmission Control Protocol (MPTCP) with mesh access is described. Thesystem includes a multi-Radio Access technology (M-RAT) base stationgateway, and a User Equipment (UE) in wireless communication with theM-RAT base station gateway. The M-RAT base station gateway has a MPTCPproxy, and proxies an initial MPTCP connection with the User Equipment(UE). The M-RAT base station gateway determines if the UE is capable ofMPTCP to provide MPTCP and when the UE is capable of MPTCP, then theM-RAT base station gateway provides a Wi-Fi connection and an LTEconnection. When the UE is not capable of MPTCP, then the M-RAT basestation gateway provides an LTE connection.

In another example embodiment, a non-transitory computer-readable mediumis provided containing instructions for providing Multipath TransmissionControl Protocol (MPTCP) wherein the instructions, when executed, causea multi-Radio Access Technology (M-RAT) base station gateway to performsteps including proxying, by a MPTCP proxy of the M-RAT base stationgateway, an initial MPTCP connection with a User Equipment (UE) anddetermining if the UE is capable of MPTCP to provide MPTCP. When the UEis capable of MPTCP, then providing a Wi-Fi connection and an LTEconnection; and when the UE is not capable of MPTCP, then providing anLTE connection.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram showing different layers and applications used inproviding MPTCP, in accordance with some embodiments.

FIG. 2 is diagram showing a MPTCP proxy construct in accordance withsome embodiments.

FIG. 3 is a diagram showing a MPTCP proxy as part of an HNG, inaccordance with some embodiments.

FIG. 4 is diagram showing a MPTCP proxy in a mobility application, inaccordance with some embodiments.

FIG. 5 is a diagram showing a first MPTCP use case for mesh backhaul, inaccordance with some embodiments.

FIG. 6 is a diagram showing a second MPTCP use case for mesh backhaul,in accordance with some embodiments.

FIG. 7 is a diagram showing RAN slicing to provide dedicated coverage todifferent types of subscribers, in accordance with some embodiments.

FIG. 8 is a diagram showing an example of MPTCP in use over an Any Garchitecture, in accordance with some embodiments.

FIG. 9 is a network diagram in accordance with some embodiments.

FIG. 10 is a network architecture diagram for 5G and other G networks.

FIG. 11 is an enhanced eNodeB for performing the methods describedherein, in accordance with some embodiments.

FIG. 12 is a coordinating server for providing services and performingmethods as described herein, in accordance with some embodiments.

DETAILED DESCRIPTION

The inventors have contemplated the use of a multipath TCP proxy (MPTCPproxy) located between the UE and the core network to provide enhancedcapacity and in some cases coverage. A MPTCP proxy is a gateway thatproxies TCP and multipath TCP connections passing through it, and thattransparently acts as a back-to-back user agent (B2BUA) for convertingordinary TCP flows into MPTCP flows and vice versa. MPTCP involves theuse of multiple subflows, which are determined at the time of TCPhandshake and which can be updated later. The MPTCP proxy thereforeproxies any TCP connection at the handshake stage to determine whatsubflows are available, and subsequently manages the subflows that areavailable. The MPTCP proxy is situated between the two endpoints of theTCP connection, which are the UE and the application server/destinationof the UE's data flow; there are several appropriate locations for aMPTCP proxy in the network as described herein. Noteworthy is that theMPTCP proxy can be situated in the cellular core network upstream fromthe RAN, meaning that it is possible to make the MPTCP proxy agnostic of(1) UE radio access technology (RAT); and (2) RAN backhaul.

The MPTPC proxy can add or delete subflows as appropriate. For example,the MPTCP proxy can determine whether to add or delete subflows basedon: (1) receiving a notification from the UE that it has (re-)connectedto a particular access network; (2) receiving a notification from acellular or Wi-Fi or Internet core network that the UE has(re-)connected to a particular access network; (3) receiving anotification from a core network that a link is available or less ormore congested; (4) based on a congestion control algorithm; (5) basedon information regarding UE capabilities, such as RAT capabilities; (6)based on information regarding global network conditions and topology;(7) based on information regarding the destination of a givenconnection; (8) any combination of the above. For example, in the usecase of providing wireless access at a sporting event stadium, with aMPTCP proxy located at the stadium, the MPTCP proxy may provide specialrules to enable UEs to watch instant replay video streams via subflowsthat use Wi-Fi and local cellular subflows (subflows that do not transitthe cellular core network), as the MPTCP proxy is aware that such datais locally cached at the stadium and are able to be downloaded to the UEwithout transiting the core network. This takes into account informationabout the topology of the network, about the location of the cacheddata, and about the RAT capabilities of the UEs.

The core networks as described herein may be cellular, Wi-Fi, Internet,Internet Multimedia Subsystem (IMS), 2G, 3G, 4G/5G EPC, 5G SA/NSA,multiple core networks, multi-operator core networks (MOCN), or anyother core network, as appropriate. In some embodiments, the Babelprotocol (see IETF RFC 6126, hereby incorporated by reference) could beused to provide simplifications to MPTCP client and MPTCP proxyconfiguration and in particular dynamic configuration of routes at aMPTCP proxy acting as a MPTCP client.

In some embodiments, an increase in both capacity and coverage isenabled. Capacity is increased because a MPTCP proxy located between theRAN and the Internet enables the use of Wi-Fi offload to delivertraffic. The MPTCP proxy is therefore able to increase effectivecapacity from the capacity of the cellular core network to the sum ofthe Wi-Fi backhaul and cellular core network by using Wi-Fi offload.Coverage can also be increased using MPTCP and mesh backhaul. Mesh asreferenced herein can refer to the use of (1) three or more basestations connected wirelessly using a standard Wi-Fi connection, using aBabel protocol to self-configure routes among themselves; or (2) anywireless backhaul capability. Wirelessly backhauled Wi-Fi access pointscan quickly provide increased coverage for UEs with Wi-Fi capabilitywith a minimum of configuration; the use of a MPTCP proxy enables UEsconnected to these APs to leverage the Wi-Fi APs for Wi-Fi calling viasecure wireless gateways such as TWAGs or ePDGs, as well as using theWi-Fi APs for as much or as little throughput as needed to bypass oraugment the capacity of the cellular data network.

Based on UE's content request, in some embodiments a Traffic Manager(TM) automatically triggers either full-mode or single-path-mode ofMPTCP. Local caching is based on the most recent content popularity. ACKpacing is automatically adjusted based on the network congestion status.

In some embodiments, the MPTCP proxy determines whether the UE iscapable of MPTCP at TCP handshake time. In other embodiments, thedetermination is based on: UE stored data at the core network; equipmentinformation of the UE that is transmitted or stored or requested,including stored IMSI; heuristics for determining generally what classof device the UE is (for example, what version of Apple iOS issupported).

Where the word UE is used herein it is understood to encompass, whereappropriate, a base station connected via a mesh link that could be thebeneficiary of MPTCP, for example to increase backhaul capacity.

MPTCP proxying is independent of logical interface construct,independent of IP address changes, and permits multiple TCP connectionsto co-exist. UDP handover is handled via S2a. All MPTCP flows areproxied via HNG and UE applications needs to support MPTCP.

Cellular operators can leverage the MPTCP to offload the traffic toWi-Fi infrastructure and to provide higher throughput. This will allowthem to save Capex/Opex for cellular networks.

Wi-Fi operators can provide better coverage: hotel—where Wi-Fi coveragecan be choppy; in this case they can leverage the cellular network anduse the MPTCP to create flows using both the Wi-Fi and LTE/3G,enterprise—in case Wi-Fi signal strength is weak, they can use the Wi-Fiand LTE/3G for data intensive applications. Better user quality ofexperience is provided as well as seamless handover from one interfaceto another in case of connectivity problems, and higher throughput.

Subscribers with MPTCP UEs can take advantage of both and load balancefor high bandwidth applications. Example applications include on-demandvideo, broadcast video and video sharing.

The present disclosure makes various references to a HNG (HetNetGateway). With respect to the Parallel Wireless HNG, details pertainingto the HNG are found in the publications incorporated herein byreference. For example, the HNG is a virtualizing server that providesconfiguration and multi-RAT interworking and proxying to a plurality ofbase stations that it manages. However, the inventors do not intend anyloss of generality thereby, and generally understand that thefunctionality described herein, including MPTCP functionality, can beprovided at any suitably-situated gateway.

Similarly, the present disclosure makes references to a CWS (ConvergedWireless System, which details are found in the publicationsincorporated herein by reference. For example, the CWS is a multi-RATbase station (providing combinations of 2G/3G/4G/5G/Wi-Fi/TVWS, etc.)that also provides Wi-Fi and LTE wireless backhaul capability, and insome cases is able to operate as a non-fixed base station (the basestation itself is mobile). However, the inventors do not intend any lossof generality thereby, and generally understand that the functionalitydescribed herein, including MPTCP functionality, can be provided at anysuitably-situated base station and/or access point.

FIG. 1 shows different layers of the OSI model generally identifying theoperation of MPTCP. Shown are the application layer 10 (layer 7), thetransport layer 101 (layer 4), the network layer 102 (layer 3), the datalink layer 103 (layer 2) the physical layer 104 (layer 1). Theapplication layer 100 has a socket to the transport layer 101. Thetransport layer includes the socket 105, which sits on top of amultipath TCP layer 106. The MPTCP layer integrates multiple TCPsubflows 107, 108, . . . 109 and determines when to add/delete subflows,and determines which subflows to use when a request to send data isreceived from application 100 via socket 105. When data comes in via anyof the subflows 107, 108, . . . 109, the MPTCP layer 106 reorders andintegrates the received data and provides it in order to socket 105.

An example MPTCP proxy construct is shown in FIG. 2, in accordance withsome embodiments. A host device (app server, which may not supportMPTCP) includes an application layer 200, a TCP layer 201 and an IPlayer 202. An MPTCP proxy 203 (identified as LAC or Parallel WirelessLTE Access Controller, which is an HNG) receives the TCP packets,transparently proxies the TCP connection, and uses the TCP, relay MPTCP,and subflow components to perform MPTCP proxying. The resulting MPTCPflows and subflows are passed to a UE 204 which supports MPTCP.

Additional scenarios are contemplated. The use of two MPTCP proxies canenable the use of MPTCP for both UEs and hosts that do and do notsupport MPTCP. For example, in the case of a UE that does not supportMPTCP and a host server that does not support MPTCP, two MPTCP proxiescan be used, one near the access base station and one near theInternet/core network egress. The access MPTCP proxy can transparentlyturn the originating TCP flow into several MPTCP subflows and use avariety of routes to connect to the core network MPTCP proxy (therebyincreasing capacity), and the core network MPTCP proxy can transparentlyturn the MPTCP subflows into a single egress TCP flow. Different MPTCPproxies may be positioned based on network topology and bandwidthconsiderations.

FIG. 3 shows a an MPTCP proxy 301 as part of the HNG 300, in accordancewith some embodiments. The MPTCP Proxy 301 performs as a proxy relay incase the app server does not support MPTCP. The MPTCP proxy alsoprovides transparent forwarding if the app-server supports MPTCP. Alsoprovided is native TCP optimization (ACK acceleration) to improvethroughput. (Wherever a MPTCP proxy is identified herein, TCPoptimization is contemplated.)

FIG. 4 shows a wireless system featuring an HNG 400 including an MPTCPproxy 401, in some embodiments. In such a system simultaneous LTE andWi-Fi access are provided to a UE supporting MPTCP via an in-vehiclebase station (in-vehicle CWS). In operation, the UE is initially coveredby a standard macro LTE base station. The initial MPTCP connection isproxied by the HNG at the point of egress from the operator's EPC corenetwork to the Internet. When the UE gets on the bus, the followingtakes place: if the Wi-Fi capacity is sufficient, the CWS will provideboth Wi-Fi and LTE connection (to increase the throughput). UserDatagram Protocol (UDP) traffic is carried via the Wi-Fi connection andre-anchored to PGW by HNG via the S2a interface, therefore the IPaddress is kept the same after attach to the CWS. If Wi-Fi capacity islimited, CWS will provide LTE connection only. The LTE local servingtraffic (within the bus) will be relayed by the CWS to a macro basestation via LTE backhaul, as shown. The MPTCP connection established inall scenarios will be proxied by the HNG. When the UE leaves the bus,the MPTCP connection is handed out via macro LTE and also proxied by theHNG. In all cases, the Wi-Fi to LTE handover is transparent to the UE,since the TCP connection is maintained at the HNG and the host device orapp server is able to continuously send data to the HNG via regular TCP,while the HNG uses MPTCP via two segments (Wi-Fi via the CWS, and LTEvia the macro base station) to send data to and from the UE.

FIG. 5 shows an MPTCP use case for mesh backhaul, in accordance withsome embodiments. In this example, the MPTCP client 500 is located atthe base station closest to the UE (i.e., the edge base station), andpermits the use of multiple backhaul links for all of its traffic viaWi-Fi mesh and subflows 501 and 502. Subflow 501 exits via one LTEbackhaul connection to a macro eNodeB. Subflow 502 exits via another LTEbackhaul connection to the same macro eNodeB. Since two LTE backhaulconnections are used, 2× the LTE air interface throughput is enabled tobe provided as backhaul for the edge base station with MPTCP client 500.

Continuing through the network, the subflows transit through the corenetwork (macro EPC) until they reach the HNG 503, which sits between thecore network and the Internet (not shown). The MPTCP proxy server at HNG503 proxies the MPTCP flow from the MPTCP client 500 back to a singleTCP flow.

In some embodiments, the edge base station uses an IPsec tunnel forbackhauling, terminating at HNG 503. In some embodiments, the MPTCP flowshown can be used to carry an IPsec tunnel providing backhaul for allUEs connected to the edge base station. In some embodiments, multipleMPTCP flows can be carried via (are encapsulated in) multiple IPsectunnels and rejoined at HNG 503.

FIG. 6 shows another MPTCP use case for mesh backhaul, in accordancewith some embodiments. In this example, the edge base station has aMPTCP client 600 and is connected via Wi-Fi mesh to two additional basestations. One of the mesh base stations has LTE backhaul and supportsMPTCP flow #2 601. The other mesh base station has wired backhaul andsupports MPTCP flow #1 602. The MPTCP flows 601 and 602 transit throughthe EPC and are rejoined at MPTCP proxy server at HNG 603. In thisscenario, the base station with wired backhaul can perform backhaulingof both of the other base stations using the capacity of its wiredconnection, and dynamic routing using Babel can be used for both MPTCPand for regular TCP within the mesh.

FIG. 7 shows an example of providing prioritized coverage to differenttypes of subscribers, in accordance with some embodiments. “Any G” isshown; in reality each of a selection of RATs would be provided, basedon operator needs. However, the architecture shown is able to be usedwith 2G/3G/4G/5G/Wi-Fi/other RATs. Three types of services are shown inthis example, best effort services 700, premium services 701, andemergency services 702, provided over Any G. An HNG with integrated core704 is provided, with the any-G base stations being managed using a homeeNodeB gateway and virtual eNodeB virtualizing gateway, which providesnecessary information to MME and SGW within the integrated core. TheHeNB GW/vENB also provides connections to operator #1 and operator #2core networks, thereby enabling neutral host and RAN sharingcapabilities for the Any G base stations. For more information about theinterworking of multiple RATs to this architecture, the reader isdirected to review the references incorporated by reference herein.

A PGW is also provided, with the PGW having egress links to theInternet, as well as to local content and to VoLTE/VoWiFi voice corenetworks. Local content is a frequently cited application/use case thatcan be enabled using this architecture; specifically, video content thatis cached near the HNG can be provided at high speed without the need totransit the Internet or an operator core network. Examples ofappropriate locations for this architecture include, e.g., hotels;resorts; sports venues; performance venues; airplanes, buses, ships, orother mobile passenger vehicles; enterprises; office towers;municipalities; etc. Shared licensed and unlicensed spectrum could beused for Any G access. Wireless backhaul, including licensed andunlicensed spectrum, could be used.

Prioritization or network slices can be enabled as described by, e.g.,5G or DSCP or QoS, to offer differentiated service for specific userprofiles. Example applications include augmented reality, broadcastvideo and video sharing. Undifferentiated Internet data can be providedvia the PGW Internet and local content egresses and high-priority orvoice data can be provided using the operator core networks.

FIG. 8 shows an example of MPTCP in use over an Any G architecture, inaccordance with some embodiments. Flows 800, 801, 802 show a variety ofUEs that are connected via a variety of RATs to base stations 804; here,UE 803 is connected via Any G (e.g., a particular RAT such as 4G) andWi-Fi, with other UEs being connected via other RATs such as two formsof Wi-Fi. Any combination of RATs is understood to be contemplated bythe inventors. Base stations 804 include an Any G base station and aPublic Wi-Fi access point. The Any G base station (here, assume 4G) isconnected via an HeNB GW/vENB that is part of Parallel Wireless HNG 805integrated core network. HNG 805 is redundantly configured. The PublicWi-Fi AP is connected via an ePDG that is part of HNG 805 integratedcore network. UE 803 is MPTCP-capable.

In operation, the UE 803 makes a request to open a connection with ahost server (not shown) via the Internet 806. However, assume the hostserver does not support MPTCP. During TCP handshaking, PGW/MPTCP proxy805 a reports that MPTCP is available, causing UE 803 to establish twosubflows, 803 a and 803 b. Subflow 803 a is transmitted over Wi-Fi viathe Wi-Fi AP and ePDG. Subflow 803 b is transmitted via the cellularRAT. Both subflows 803 a and 803 b are joined at PGW/MPTCP proxy 805 a,which transparently turns the MPTCP flow into a non-multipath TCP flowbefore sending it out over the Internet 806 to the host server. Thisresults in a significant increase in throughput to UE 803, and alsoresults in some offload of the SGW and other core network nodes.

If the host server supports MPTCP, MPTCP proxy 805 a will operatesimilarly but will transparently forward all MPTCP traffic to theMPTCP-capable host server. In the case of local content, the MPTCP flowswill not be bandwidth-constrained when sending data to and from the hostserver, so the any G base stations and Wi-Fi APs will be able to routesubflows to take advantage of all radio channels that are availablebased on local RF conditions.

In some embodiments, any combination of RATs can be used for MPTCP. Forexample: 5G NR and Wi-Fi can be combined to provide high throughput forbandwidth-hungry users. MPTCP may combine 4G and 5G; 4G with 3G; 4G withWi-Fi; 2G with 3G; 2G and 4G; or any other combination thereof. MPTCPmay take into account multiple topologies, for example, treating IPpaths that bypass the cellular core network as separate paths even ifthey are enabled by the same or different RATs (for example, Wi-Fiproviding a connection to both the local network and the core network).MPTCP may be combined with quality of service and/or network slicing,and the MPTCP proxy may be aware of the different networkcapabilities/speeds/performance guarantees available to different flows,and may perform routing to subflows that are appropriate for theapplication (for example, low-latency applications may be directed tolow-latency subflows). Mesh base stations, moving base stations,self-organizing base stations, and base stations with intermittentlyavailable backhaul links may be supported. In some embodiments, thequality of links can be assessed in real time (mesh links, RAT links aswell as subflows), and subflow routing can be adjusted by the MPTCPproxy in real time.

In some embodiments, given the nature of the capacity requirement forapplications like a stadium is on-demand, a fleet of drones can bedispatched with CWS onboard to enable such on-demand capacity. Thisflying-cell-fleet approach would leverage 3 strengths on our side:ad-hoc (in-sync w/our mesh approach), mesh and MPTCP. As long as thebattery on the drone can sustain up to 5+ hours, it would be sufficientto cover most or all users in the stadium for the duration of mostsporting events. For more details regarding ad-hoc configurationcapability as applied to base stations and mobile base stations, thereader is invited to review the documents incorporated by referenceabove.

Multi-backhaul as well as multiple paths would be supported (fiber,satellite, 3G, 4G, 5G) and would operate to complement local breakoutfor IP traffic, for example, this would support different routing forvideo feeds that are actually supplied within the stadium (e.g., instantreplays). MPTCP proxy could detect whether core network nodes, PCRF,etc. support MPTCP and adjust proxying accordingly for all flows to anyof these nodes.

The multipath TCP proxy described herein could operate similar to thatdescribed in US20120331160, hereby incorporated by reference in itsentirety for all purposes.

In one embodiment a method for providing Multipath Transmission ControlProtocol (MPTCP) with mesh access includes proxying, by a multi-RadioAccess Technology (RAT) base station having a MPTCP proxy, an initialMPTCP connection from a User Equipment (UE) and determining, by themulti-RAT base station, if the UE is capable of MPTCP to provide MPTCP.The method also includes when the UE is capable of MPTCP, thenproviding, by the multi-RAT base station, a Wi-Fi connection and an LTEconnection; and when the UE is not capable of MPTCP, then providing, bythe multi-RAT base station, an LTE connection. The method may alsoinclude, when the UE is capable of MPTCP, carrying UDP traffic via theWi-Fi connection and re-anchored to the packet data network gateway(PGW) by the multi-RAT base station via an S2a interface. The method mayfurther include, when the UE is not capable of MPTCP, relaying the LTElocal serving traffic to a macro. The base station may be one or more ofa mobile base station, a self-organizing base station and a mesh basestation.

In another embodiment, a method for providing Multipath TransmissionControl Protocol (MPTCP) with mesh access, includes proxying, by amulti-Radio Access Technology (RAT) base station having a MPTCP proxy,an initial MPTCP connection from a User Equipment (UE) and determining,by the multi-RAT base station, if there is sufficient 5G capacity toprovide MPTCP. The method may also include, when there is sufficient 5Gcapacity, then providing, by the multi-RAT base station, a 5G connectionand a 4G connection; and when there is insufficient 5G capacity, thenproviding, by the multi-RAT base station, a 4G connection. The methodmay further include, when there is sufficient 5G-Fi capacity, carryingUDP traffic via the 5G connection and re-anchored to the packet datanetwork gateway (PGW) by the multi-RAT base station via an S2ainterface. The method may also include, when there is insufficient 5Gcapacity, relaying the 4G local serving traffic to a macro. The basestation may be one or more of a mobile base station, a self-organizingbase station and a mesh base station.

In another embodiment, a method for providing Multipath TransmissionControl Protocol (MPTCP) with mesh access, includes proxying, by amulti-Radio Access Technology (RAT) base station having a MPTCP proxy,an initial MPTCP connection from a User Equipment (UE) and determining,by the multi-RAT base station, if there is sufficient cellular capacityto provide MPTCP; and when there is sufficient cellular capacity, thenproviding, by the multi-RAT base station, a cellular connection and aWi-Fi connection; and when there is insufficient cellular capacity, thenproviding, by the multi-RAT base station, a Wi-Fi connection. The methodmay further include, when there is sufficient cellular capacity,carrying UDP traffic via the cellular connection and re-anchored to thepacket data network gateway (PGW) by the multi-RAT base station via anS2a interface. The method may also include, when there is insufficientcellular capacity, relaying the Wi-Fi local serving traffic to a macro.The base station may be one or more of a mobile base station, aself-organizing base station and a mesh base station.

In another example embodiment, a method for providing MultipathTransmission Control Protocol (MPTCP) with mesh access includesproxying, by a multi-Radio Access Technology (RAT) base station having aMPTCP proxy, an initial MPTCP connection from a User Equipment (UE) anddetermining, by the multi-RAT base station, if there is sufficientcapacity for a first RAT to provide MPTCP. The method further includes,when there is sufficient capacity using the first RAT, then providing,by the multi-RAT base station, a connection using the first RAT and aconnection using a second RAT different from the first RAT, wherein thefirst RAT provides Quality of Service (QoS) and wherein the second RATdoes not provide QoS; and when there is insufficient capacity, thenproviding, by the multi-RAT base station, a second RAT connection. Thebase station may be one or more of a mobile base station, aself-organizing base station and a mesh base station.

In another example embodiment, a method for providing MultipathTransmission Control Protocol (MPTCP) with mesh access includesproxying, by a multi-Radio Access Technology (RAT) base station having aMPTCP proxy, an initial MPTCP connection from a User Equipment (UE), anddetermining, by the multi-RAT base station, if there is sufficientcapacity for a first RAT to provide MPTCP. When there is sufficientcapacity using the first RAT, then providing, by the multi-RAT basestation, a connection using the first RAT and a connection using asecond RAT different from the first RAT, wherein the first RAT providesnetwork slicing; and when there is insufficient capacity, thenproviding, by the multi-RAT base station, a second RAT connection. Thebase station may be one or more of a mobile base station, aself-organizing base station and a mesh base station.

FIG. 9 is a network diagram in accordance with some embodiments. In someembodiments, as shown in FIG. 9, a mesh node 1 901, a mesh node 2 902,and a mesh node 3 903 are any G RAN nodes. Base stations 901, 902, and903 form a mesh network establishing mesh network links 906, 907, 908,909, and 910 with a base station 904. The mesh network links areflexible and are used by the mesh nodes to route traffic aroundcongestion within the mesh network as needed. The base station 904 actsas gateway node or mesh gateway node, and provides backhaul connectivityto a core network to the base stations 901, 902, and 903 over backhaullink 914 to a coordinating server(s) 905 and towards core network 915.The Base stations 901, 902, 903, 904 may also provide eNodeB, NodeB,Wi-Fi Access Point, Femto Base Station etc. functionality, and maysupport radio access technologies such as 2G, 3G, 4G, 5G, Wi-Fi etc. Thebase stations 901, 902, 903 may also be known as mesh network nodes 901,902, 903.

The coordinating servers 905 are shown as two coordinating servers 905 aand 905 b. The coordinating servers 905 a and 905 b may be inload-sharing mode or may be in active-standby mode for highavailability. The coordinating servers 905 may be located between aradio access network (RAN) and the core network and may appear as corenetwork to the base stations in a radio access network (RAN) and asingle eNodeB to the core network, i.e., may provide virtualization ofthe base stations towards the core network. As shown in FIG. 9, varioususer equipments 911 a, 911 b, 911 c are connected to the base station901. The base station 901 provides backhaul connectivity to the userequipments 911 a, 911 b, and 911 c connected to it over mesh networklinks 906, 907, 908, 909, 910 and 914. The user equipments may be mobiledevices, mobile phones, personal digital assistant (PDA), tablet, laptopetc. The base station 902 provides backhaul connection to userequipments 912 a, 912 b, 912 c and the base station 903 providesbackhaul connection to user equipments 913 a, 913 b, and 913 c. The userequipments 911 a, 911 b, 911 c, 912 a, 912 b, 912 c, 913 a, 913 b, 913 cmay support any radio access technology such as 2G, 3G, 4G, 5G, Wi-Fi,WiMAX, LTE, LTE-Advanced etc. supported by the mesh network basestations, and may interwork these technologies to IP.

In some embodiments, depending on the user activity occurring at theuser equipments 911 a, 911 b, 911 c, 912 a, 912 b, 912 c, 913 a, 913 b,and 913 c, the uplink 914 may get congested under certain circumstances.As described above, to continue the radio access network running andproviding services to the user equipments, the solution requiresprioritizing or classifying the traffic based at the base stations 901,902, 903. The traffic from the base stations 901, 902, and 903 to thecore network 915 through the coordinating server 905 flows through anIPSec tunnel terminated at the coordinating server 905. The mesh networknodes 901, 902, and 903 adds IP Option header field to the outermost IPHeader (i.e., not to the pre-encapsulated packets). The traffic may fromthe base station 901 may follow any of the mesh network link path suchas 907, 906-110, 906-108-109 to reach to the mesh gateway node 904,according to a mesh network routing protocol.

FIG. 10 is a network architecture diagram for 5G and other-G networks.The diagram shows a plurality of “Gs,” including 2G, 3G, 4G, 5G andWi-Fi. 2G is represented by GERAN 1001, which includes a 2G device 1001a, BTS 1001 b, and BSC 1001 c. 3G is represented by UTRAN 1002, whichincludes a 3G UE 1002 a, nodeB 1002 b, RNC 1002 c, and femto gateway(FGW, which in 3GPP namespace is also known as a Home nodeB Gateway orHNBGW) 1002 d. 4G is represented by EUTRAN or E-RAN 1003, which includesan LTE UE 1003 a and LTE eNodeB 1003 b. Wi-Fi is represented by Wi-Fiaccess network 1004, which includes a trusted Wi-Fi access point 1004 cand an untrusted Wi-Fi access point 1004 d. The Wi-Fi devices 1004 a and1004 b may access either AP 1004 c or 1004 d. In the current networkarchitecture, each “G” has a core network. 2G circuit core network 1005includes a 2G MSC/VLR; 2G/3G packet core network 1006 includes anSGSN/GGSN (for EDGE or UMTS packet traffic); 3G circuit core 1007includes a 3G MSC/VLR; 4G circuit core 1008 includes an evolved packetcore (EPC); and in some embodiments the Wi-Fi access network may beconnected via an ePDG/TTG using S2a/S2b. Each of these nodes areconnected via a number of different protocols and interfaces, as shown,to other, non-“G”-specific network nodes, such as the SCP 1030, the SMSC1031, PCRF 1032, HLR/HSS 1033, Authentication, Authorization, andAccounting server (AAA) 1034, and IP Multimedia Subsystem (IMS) 1035. AnHeMS/AAA 1036 is present in some cases for use by the 3G UTRAN. Thediagram is used to indicate schematically the basic functions of eachnetwork as known to one of skill in the art, and is not intended to beexhaustive. For example, 5G core 1017 is shown using a single interfaceto 5G access 1016, although in some cases 5G access can be supportedusing dual connectivity or via a non-standalone deployment architecture.

Noteworthy is that the RANs 1001, 1002, 1003, 1004 and 1036 rely onspecialized core networks 1005, 1006, 1007, 1008, 1009, 1037 but shareessential management databases 1030, 1031, 1032, 1033, 1034, 1035, 1038.More specifically, for the 2G GERAN, a BSC 1001 c is required for Abiscompatibility with BTS 1001 b, while for the 3G UTRAN, an RNC 1002 c isrequired for Iub compatibility and an FGW 1002 d is required for Iuhcompatibility. These core network functions are separate because eachRAT uses different methods and techniques. On the right side of thediagram are disparate functions that are shared by each of the separateRAT core networks. These shared functions include, e.g., PCRF policyfunctions, AAA authentication functions, and the like. Letters on thelines indicate well-defined interfaces and protocols for communicationbetween the identified nodes.

FIG. 11 is an enhanced eNodeB for performing the methods describedherein, in accordance with some embodiments. Mesh network node 1100 mayinclude processor 1102, processor memory 1104 in communication with theprocessor, baseband processor 1106, and baseband processor memory 1108in communication with the baseband processor. Mesh network node 1100 mayalso include first radio transceiver 1112 and second radio transceiver1114, internal universal serial bus (USB) port 1116, and subscriberinformation module card (SIM card) 1118 coupled to USB port 1116. Insome embodiments, the second radio transceiver 1114 itself may becoupled to USB port 1116, and communications from the baseband processormay be passed through USB port 1116. The second radio transceiver may beused for wirelessly backhauling eNodeB 1100.

Processor 1102 and baseband processor 1106 are in communication with oneanother. Processor 1102 may perform routing functions, and may determineif/when a switch in network configuration is needed. Baseband processor1106 may generate and receive radio signals for both radio transceivers1112 and 1114, based on instructions from processor 1102. In someembodiments, processors 1102 and 1106 may be on the same physical logicboard. In other embodiments, they may be on separate logic boards.

Processor 1102 may identify the appropriate network configuration, andmay perform routing of packets from one network interface to anotheraccordingly. Processor 1102 may use memory 1104, in particular to storea routing table to be used for routing packets. Baseband processor 1106may perform operations to generate the radio frequency signals fortransmission or retransmission by both transceivers 1110 and 1112.Baseband processor 1106 may also perform operations to decode signalsreceived by transceivers 1112 and 1114. Baseband processor 1106 may usememory 1108 to perform these tasks.

The first radio transceiver 1112 may be a radio transceiver capable ofproviding LTE eNodeB functionality, and may be capable of higher powerand multi-channel OFDMA. The second radio transceiver 1114 may be aradio transceiver capable of providing LTE UE functionality. Bothtransceivers 1112 and 1114 may be capable of receiving and transmittingon one or more LTE bands. In some embodiments, either or both oftransceivers 1112 and 1114 may be capable of providing both LTE eNodeBand LTE UE functionality. Transceiver 1112 may be coupled to processor1102 via a Peripheral Component Interconnect-Express (PCI-E) bus, and/orvia a daughtercard. As transceiver 1114 is for providing LTE UEfunctionality, in effect emulating a user equipment, it may be connectedvia the same or different PCI-E bus, or by a USB bus, and may also becoupled to SIM card 1118. First transceiver 1112 may be coupled to firstradio frequency (RF) chain (filter, amplifier, antenna) 1122, and secondtransceiver 1114 may be coupled to second RF chain (filter, amplifier,antenna) 1124.

SIM card 1118 may provide information required for authenticating thesimulated UE to the evolved packet core (EPC). When no access to anoperator EPC is available, a local EPC may be used, or another local EPCon the network may be used. This information may be stored within theSIM card, and may include one or more of an international mobileequipment identity (IMEI), international mobile subscriber identity(IMSI), or other parameter needed to identify a UE. Special parametersmay also be stored in the SIM card or provided by the processor duringprocessing to identify to a target eNodeB that device 1100 is not anordinary UE but instead is a special UE for providing backhaul to device1100.

Wired backhaul or wireless backhaul may be used. Wired backhaul may bean Ethernet-based backhaul (including Gigabit Ethernet), or afiber-optic backhaul connection, or a cable-based backhaul connection,in some embodiments. Additionally, wireless backhaul may be provided inaddition to wireless transceivers 1112 and 1114, which may be Wi-Fi802.11a/b/g/n/ac/ad/ah, Bluetooth, ZigBee, microwave (includingline-of-sight microwave), or another wireless backhaul connection. Anyof the wired and wireless connections described herein may be usedflexibly for either access (providing a network connection to UEs) orbackhaul (providing a mesh link or providing a link to a gateway or corenetwork), according to identified network conditions and needs, and maybe under the control of processor 1102 for reconfiguration.

A GPS module 1130 may also be included, and may be in communication witha GPS antenna 1132 for providing GPS coordinates, as described herein.When mounted in a vehicle, the GPS antenna may be located on theexterior of the vehicle pointing upward, for receiving signals fromoverhead without being blocked by the bulk of the vehicle or the skin ofthe vehicle. Automatic neighbor relations (ANR) module 1132 may also bepresent and may run on processor 1102 or on another processor, or may belocated within another device, according to the methods and proceduresdescribed herein.

Other elements and/or modules may also be included, such as a homeeNodeB, a local gateway (LGW), a self-organizing network (SON) module,or another module. Additional radio amplifiers, radio transceiversand/or wired network connections may also be included.

FIG. 12 is a coordinating server for providing services and performingmethods as described herein, in accordance with some embodiments.Coordinating server 1200 includes processor 1202 and memory 1204, whichare configured to provide the functions described herein. Also presentare radio access network coordination/routing (RAN Coordination androuting) module 1206, including ANR module 1206 a, RAN configurationmodule 1208, and RAN proxying module 1210. The ANR module 1206 a mayperform the ANR tracking, PCI disambiguation, ECGI requesting, and GPScoalescing and tracking as described herein, in coordination with RANcoordination module 1206 (e.g., for requesting ECGIs, etc.). In someembodiments, coordinating server 1200 may coordinate multiple RANs usingcoordination module 1206. In some embodiments, coordination server mayalso provide proxying, routing virtualization and RAN virtualization,via modules 1210 and 1208. In some embodiments, a downstream networkinterface 1212 is provided for interfacing with the RANs, which may be aradio interface (e.g., LTE), and an upstream network interface 1214 isprovided for interfacing with the core network, which may be either aradio interface (e.g., LTE) or a wired interface (e.g., Ethernet).

Coordinator 1200 includes local evolved packet core (EPC) module 1220,for authenticating users, storing and caching priority profileinformation, and performing other EPC-dependent functions when nobackhaul link is available. Local EPC 1220 may include local HSS 1222,local MME 1224, local SGW 1226, and local PGW 1228, as well as othermodules. Local EPC 1220 may incorporate these modules as softwaremodules, processes, or containers. Local EPC 1220 may alternativelyincorporate these modules as a small number of monolithic softwareprocesses. Modules 1206, 1208, 1210 and local EPC 1220 may each run onprocessor 1202 or on another processor, or may be located within anotherdevice.

In any of the scenarios described herein, where processing may beperformed at the cell, the processing may also be performed incoordination with a cloud coordination server. A mesh node may be aneNodeB. An eNodeB may be in communication with the cloud coordinationserver via an X2 protocol connection, or another connection. The eNodeBmay perform inter-cell coordination via the cloud communication server,when other cells are in communication with the cloud coordinationserver. The eNodeB may communicate with the cloud coordination server todetermine whether the UE has the ability to support a handover to Wi-Fi,e.g., in a heterogeneous network.

The protocols described herein have largely been adopted by the 3GPP asa standard for the upcoming 5G network technology as well, in particularfor interfacing with 4G/LTE technology. For example, X2 is used in both4G and 5G and is also complemented by 5G-specific standard protocolscalled Xn. Additionally, the 5G standard includes two phases,non-standalone (which will coexist with 4G devices and networks) andstandalone, and also includes specifications for dual connectivity ofUEs to both LTE and NR (“New Radio”) 5G radio access networks. Theinter-base station protocol between an LTE eNB and a 5G gNB is calledXx. The specifications of the Xn and Xx protocol are understood to beknown to those of skill in the art and are hereby incorporated byreference dated as of the priority date of this application. MultipathTCP could be used with 4G, 5G, both, together, separately, etc. andcould be used with IPv4 as well as IPv6. Mixing IPv4 and IPv6 would bepossible, in some embodiments.

In some embodiments, several nodes in the 4G/LTE Evolved Packet Core(EPC), including mobility management entity (MME), MME/serving gateway(S-GW), and MME/S-GW are located in a core network. Where shown in thepresent disclosure it is understood that an MME/S-GW is representing anycombination of nodes in a core network, of whatever generationtechnology, as appropriate. The present disclosure contemplates agateway node, variously described as a gateway, HetNet Gateway,multi-RAT gateway, LTE Access Controller, radio access networkcontroller, aggregating gateway, cloud coordination server, coordinatinggateway, or coordination cloud, in a gateway role and position betweenone or more core networks (including multiple operator core networks andcore networks of heterogeneous RATs) and the radio access network (RAN).This gateway node may also provide a gateway role for the X2 protocol orother protocols among a series of base stations. The gateway node mayalso be a security gateway, for example, a TWAG or ePDG. The RAN shownis for use at least with an evolved universal mobile telecommunicationssystem terrestrial radio access network (E-UTRAN) for 4G/LTE, and for5G, and with any other combination of RATs, and is shown with multipleincluded base stations, which may be eNBs or may include regular eNBs,femto cells, small cells, virtual cells, virtualized cells (i.e., realcells behind a virtualization gateway), or other cellular base stations,including 3G base stations and 5G base stations (gNBs), or base stationsthat provide multi-RAT access in a single device, depending on context.

In the present disclosure, the words “eNB,” “eNodeB,” and “gNodeB” areused to refer to a cellular base station. However, one of skill in theart would appreciate that it would be possible to provide the samefunctionality and services to other types of base stations, as well asany equivalents, such as Home eNodeBs. In some cases, Wi-Fi may beprovided as a RAT, either on its own or as a component of a cellularaccess network via a trusted wireless access gateway (TWAG), evolvedpacket data network gateway (ePDG) or other gateway, which may be thesame as the coordinating gateway described hereinabove.

The word “X2” herein may be understood to include X2 or also Xn or Xx,as appropriate. The gateway described herein is understood to be able tobe used as a proxy, gateway, B2BUA, interworking node, interoperabilitynode, etc. as described herein for and between X2, Xn, and/or Xx, asappropriate, as well as for any other protocol and/or any othercommunications between an LTE eNB, a 5G gNB (either NR, standalone ornon-standalone). The gateway described herein is understood to besuitable for providing a stateful proxy that models capabilities of dualconnectivity-capable handsets for when such handsets are connected toany combination of eNBs and gNBs. The gateway described herein mayperform stateful interworking for master cell group (MCG), secondarycell group (SCG), other dual-connectivity scenarios, orsingle-connectivity scenarios.

In some embodiments, the base stations described herein may becompatible with a Long Term Evolution (LTE) radio transmission protocol,or another air interface. The LTE-compatible base stations may beeNodeBs, or may be gNodeBs, or may be hybrid base stations supportingmultiple technologies and may have integration across multiple cellularnetwork generations such as steering, memory sharing, data structuresharing, shared connections to core network nodes, etc. In addition tosupporting the LTE protocol, the base stations may also support otherair interfaces, such as UMTS/HSPA, CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO,other 3G/2G, legacy TDD, 5G, or other air interfaces used for mobiletelephony. In some embodiments, the base stations described herein maysupport Wi-Fi air interfaces, which may include one of802.11a/b/g/n/ac/ad/af/ah. In some embodiments, the base stationsdescribed herein may support 802.16 (WiMAX), or other air interfaces. Insome embodiments, the base stations described herein may provide accessto land mobile radio (LMR)-associated radio frequency bands. In someembodiments, the base stations described herein may also support morethan one of the above radio frequency protocols, and may also supporttransmit power adjustments for some or all of the radio frequencyprotocols supported.

The foregoing discussion discloses and describes merely exemplaryembodiments of the present invention. In some embodiments, softwarethat, when executed, causes a device to perform the methods describedherein may be stored on a computer-readable medium such as a computermemory storage device, a hard disk, a flash drive, an optical disc, orthe like. As will be understood by those skilled in the art, the presentinvention may be embodied in other specific forms without departing fromthe spirit or essential characteristics thereof. For example, wirelessnetwork topology can also apply to wired networks, optical networks, andthe like. The methods may apply to 5G networks, LTE-compatible networks,to UMTS-compatible networks, or to networks for additional protocolsthat utilize radio frequency data transmission. Various components inthe devices described herein may be added, removed, or substituted withthose having the same or similar functionality. Various steps asdescribed in the figures and specification may be added or removed fromthe processes described herein, and the steps described may be performedin an alternative order, consistent with the spirit of the invention.

Although the methods above are described as separate embodiments, one ofskill in the art would understand that it would be possible anddesirable to combine several of the above methods into a singleembodiment, or to combine disparate methods into a single embodiment.For example, all of the above methods could be combined. In thescenarios where multiple embodiments are described, the methods could becombined in sequential order, or in various orders as necessary.

Although the above systems and methods for providing interferencemitigation are described in reference to the Long Term Evolution (LTE)standard, one of skill in the art would understand that these systemsand methods could be adapted for use with other wireless standards orversions thereof.

The word “cell” is used herein to denote either the coverage area of anybase station, or the base station itself, as appropriate and as would beunderstood by one having skill in the art. For purposes of the presentdisclosure, while actual PCIs and ECGIs have values that reflect thepublic land mobile networks (PLMNs) that the base stations are part of,the values are illustrative and do not reflect any PLMNs nor the actualstructure of PCI and ECGI values.

In some embodiments, the software needed for implementing the methodsand procedures described herein may be implemented in a high levelprocedural or an object-oriented language such as C, C++, C#, Python,Java, or Perl. The software may also be implemented in assembly languageif desired. Packet processing implemented in a network device caninclude any processing determined by the context. For example, packetprocessing may involve high-level data link control (HDLC) framing,header compression, and/or encryption. In some embodiments, softwarethat, when executed, causes a device to perform the methods describedherein may be stored on a computer-readable medium such as read-onlymemory (ROM), programmable-read-only memory (PROM), electricallyerasable programmable-read-only memory (EEPROM), flash memory, or amagnetic disk that is readable by a general or specialpurpose-processing unit to perform the processes described in thisdocument. The processors can include any microprocessor (single ormultiple core), system on chip (SoC), microcontroller, digital signalprocessor (DSP), graphics processing unit (GPU), or any other integratedcircuit capable of processing instructions such as an x86microprocessor.

In some embodiments, the radio transceivers described herein may be basestations compatible with a Long Term Evolution (LTE) radio transmissionprotocol or air interface. The LTE-compatible base stations may beeNodeBs. In addition to supporting the LTE protocol, the base stationsmay also support other air interfaces, such as UMTS/HSPA, CDMA/CDMA2000,GSM/EDGE, GPRS, EVDO, other 3G/2G, legacy TDD, or other air interfacesused for mobile telephony.

In some embodiments, the base stations described herein may supportWi-Fi air interfaces, which may include one or more of IEEE802.11a/b/g/n/ac/af/p/h. In some embodiments, the base stationsdescribed herein may support IEEE 802.16 (WiMAX), to LTE transmissionsin unlicensed frequency bands (e.g., LTE-U, Licensed Access or LA-LTE),to LTE transmissions using dynamic spectrum access (DSA), to radiotransceivers for ZigBee, Bluetooth, or other radio frequency protocols,or other air interfaces.

The foregoing discussion discloses and describes merely exemplaryembodiments of the present invention. In some embodiments, softwarethat, when executed, causes a device to perform the methods describedherein may be stored on a computer-readable medium such as a computermemory storage device, a hard disk, a flash drive, an optical disc, orthe like. As will be understood by those skilled in the art, the presentinvention may be embodied in other specific forms without departing fromthe spirit or essential characteristics thereof. For example, wirelessnetwork topology can also apply to wired networks, optical networks, andthe like. The methods may apply to LTE-compatible networks, toUMTS-compatible networks, or to networks for additional protocols thatutilize radio frequency data transmission. Various components in thedevices described herein may be added, removed, split across differentdevices, combined onto a single device, or substituted with those havingthe same or similar functionality.

Although the present disclosure has been described and illustrated inthe foregoing example embodiments, it is understood that the presentdisclosure has been made only by way of example, and that numerouschanges in the details of implementation of the disclosure may be madewithout departing from the spirit and scope of the disclosure, which islimited only by the claims which follow. Various components in thedevices described herein may be added, removed, or substituted withthose having the same or similar functionality. Various steps asdescribed in the figures and specification may be added or removed fromthe processes described herein, and the steps described may be performedin an alternative order, consistent with the spirit of the invention.Features of one embodiment may be used in another embodiment. Otherembodiments are within the following claims.

The invention claimed is:
 1. A method for providing MultipathTransmission Control Protocol (MPTCP) using a multi-radio accesstechnology (M-RAT) base station, comprising: proxying, by the M-RAT basestation gateway having a MPTCP proxy, an MPTCP connection with a UserEquipment (UE); determining by the M-RAT base station gateway, if the UEis capable of MPTCP to provide MPTCP with the UE; when the UE is capableof MPTCP, then providing, by the M-RAT base station gateway, a Wi-Ficonnection and an LTE connection as a MPTCP connection; when the UE isnot capable of MPTCP, then providing, by the M-RAT base station, an LTEconnection; and when the UE is capable of MPTCP, carrying UDP trafficvia the Wi-Fi connection and re-anchored to the packet data networkgateway (PGW) by the M-RAT base station gateway via an S2a interface,and; when the UE is not capable of MPTCP, relaying the LTE local servingtraffic to a macro.
 2. The method of claim 1 wherein the base stationgateway is one or more of a mobile base station, a self-organizing basestation and a mesh base station.
 3. The method of claim 1 furthercomprising acting, by the MPTCP proxy, as a proxy-relay when theapplication server does not support MPTCP; and providing, by the MPTCPproxy, transparent forwarding when the application server does supportMPTCP.
 4. The method of claim 1 wherein the MPTPC proxy is situatedbetween a cellular core network of the base station and the Internet,and between a security gateway of the Wi-Fi Access Point (AP) and theInternet.
 5. A method for providing Multipath Transmission ControlProtocol (MPTCP) using a multi-radio access technology (M-RAT) basestation, comprising: proxying, by the M-RAT base station gateway havinga MPTCP proxy, an initial MPTCP connection with a User Equipment (UE);determining, by the M-RAT base station gateway, if there is sufficient5G capacity to provide MPTCP; when there is sufficient 5G capacity, thenproviding, by the M-RAT base station, a 5G connection and a 4Gconnection; when there is insufficient 5G capacity, then providing, bythe multi-RAT base station, a 4G connection; and when there issufficient 5G capacity, carrying UDP traffic via the 5G connection andre-anchored to the packet data network gateway (PGW) by the M-RAT basestation gateway via an S2a interface, and; when there is insufficient 5Gcapacity, relaying the 4G local serving traffic to a macro.
 6. Themethod of claim 5 wherein the base station gateway is one or more of amobile base station, a self-organizing base station and a mesh basestation.
 7. The method of claim 5 further comprising acting, by theMPTCP proxy, as a proxy-relay when the application server does notsupport MPTCP; and providing, by the MPTCP proxy, transparent forwardingwhen the application server does support MPTCP.
 8. The method of claim 5wherein the MPTPC proxy is situated between a cellular core network ofthe base station and the Internet.
 9. A method for providing MultipathTransmission Control Protocol (MPTCP) using a multi-radio accesstechnology (M-RAT) base station, comprising: proxying, by the M-RAT basestation gateway having a MPTCP proxy, an initial MPTCP connection with aUser Equipment (UE); determining, by the multi-RAT base station, ifthere is sufficient cellular capacity to provide MPTCP with the UE; whenthere is sufficient cellular capacity, then providing, by the M-RAT basestation gateway, a cellular connection and a Wi-Fi connection; whenthere is insufficient cellular capacity, then providing, by the M-RATbase station, a Wi-Fi connection; and when there is sufficient cellularcapacity, carrying UDP traffic via the cellular connection andre-anchored to the packet data network gateway (PGW) by the M-RAT basestation gateway via an S2a interface, and; when there is insufficientcellular capacity, relaying the Wi-Fi local serving traffic to a macro.10. The method of claim 9 wherein the base station is one or more of amobile base station, a self-organizing base station and a mesh basestation.
 11. The method of claim 9 further comprising acting, by theMPTCP proxy, as a proxy-relay when the application server does notsupport MPTCP; and providing, by the MPTCP proxy, transparent forwardingwhen the application server does support MPTCP.
 12. The method of claim9 wherein the MPTPC proxy is situated between a cellular core network ofthe base station and the Internet, and between a security gateway of theWi-Fi Access Point (AP) and the Internet.